Re: PostgreSQL on Linux PC vs MacOS X

>In my experience, a G4/1.25GHz computer with standard apple drive was much
>faster than the PC (Pentium 2+GHz, don't remember details) we tested running
>Linux.  Both machines had plenty of RAM, same PostgreSQL settings,
>etc.  The PC
>was much slower than the mac running backup/restore (more than 2x
>slower).  The
>queries we tested were slower as well.  Both machines had IDE
>drives.  I'd think
>the Linux box could probably be made to be faster, but it had a long way to go
>to even match the G4.

One possible explanation for your results would be that the Mac IDE
drive lies about write completion while the PC IDE drive does not.
You mention a backup/restore test, which is very write-intensive.
Any system with an IDE drive that lies about write completion is
going to blow away (write performance-wise) a system with an IDE
drive that does not lie about it.  Our tests last year were all with
SELECT queries to prevent this factor from skewing our results.  (Our
app is read-heavy and we knew we would be getting a good hardware
RAID setup that could handle the writes.)

I do not have the same Apple hardware from a year ago to reproduce my
tests.  If I get time in the next week, I can try something on the
same PC (RedHat 9, P3/800) vs. a G4/933, OS X Server 10.2.


>We have had excellent stability on both G4 and G5, MacOS 10.2.x and 10.3.x,
>PostgreSQL 7.3.x and 7.4.x.  The only time we experienced instability was just
>after the G5 was released, the combination of G5, MacOS 10.2.7 and PostgreSQL
>7.3.x just didn't work very well.  Upgrading the G5 to MacOS 10.3.x and
>PostgreSQL 7.4.x brought back the stability we expected and we haven't really
>had any problems since.

Our primary OS X 10.2 server crashed very frequently.  Sometimes more
than once per day.  We changed machines and the crashes continued.
Apple HW test on both boxes showed no problems.  The vast majority of
these crashes were under moderate load (~120 queries/min).  A few
times, reindexing would cause a crash without any other DB activity.
With almost all of these crashes, there were no CrashReporter log
entries.  At that point, we felt like we had no recourse but to try
something different (Linux/x86) and haven't looked back.

- Jeff

--

Jeff Bohmer
VisionLink, Inc.
_________________________________
303.402.0170 x121
http://www.visionlink.org/
_________________________________
People. Tools. Change. Community.